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Anatomy of an Atomic Modeset 


1. Build up new state 
2. Compute derived state and check the update 


3. Commit the new state to the hardware, possibly 
asynchronously 
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State Building 


e per-object states structures tracked in struct 
drm atomic state 


*->atomic duplicate/destroy * per-object 


e ->atomic set/get property only for private 
properties 


e start with pure helpers, subclass as needed 
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State Checking 


° global ->atomic check entry point 
e plus big modular helper library 


e helper supports legacy ->mode_fixup and new 
->atomic check hooks 


e read the kerneldoc! 
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State Precomputing&Checking 
e often check and commit need to compute the same values, 
e.g. DP link settings 


> subclass state structures and store derived state for reuse 
in the commit phase 


e almosts everything ends up being subclassed, tons of 
examples 
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Cross-State Structures Checking 


*->atomic check hooks can look at any other state 


e always use provided functions and check errors to avoid 
wait/wound mutex headaches and unecessary serialization 


e CONFIG DEBUG WW MUTEX SLOWPATH 
e overwrite global ->atomic_check If needed 


e tons of examples already 


OpenSource 6 


Handling Global State 


e for shared resources across CRTCS 


e use driver-private w/w mutex or dev->mode config- 
>connection mutex 


*->atomic state alloc/clear/free to subclass 
global struct drm atomic state 


e currently only i915: display core clock, shared PLLS, ... 
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State Committing 


° global ->atomic commit entry point 

e commit not allowed to fail due to invalid state 

* core guarantees to call ->atomic_check first 

e helpers by default optimized for backwards compat 


e modular helpers to accomodate more drivers, read docs! 
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Helper Design 

e plane updates orthogonal to modeset changes 

° no parital enables/disable, reducing complexity 

e DPMS implemented entirely in helpers 

e lots of old hooks depracated, most others optional 
e legacy state updated by default, but can be ignored 


> much fewer boilerplate required 
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Atomic Commit Flow 


*->prepare fb for memory alloc, pinning 

e swap new state into objects (must be done synchronously) 
e wait for fences and buffers 

e actual hardware commit, built from helpers and driver code 
e wait for vblank 


*->cleanup fb to for memory release, unpin 
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Hardware Commit Helpers 

e CRTC, encoders and bridges for modesets with just 
enable/disable hooks 

e 3-phase plane updates: 


1. CRTC ->atomic begin for vblank evade, blocking 
updates 


2. per-plane ->atomic update/disable 
3.CRTC ->atomic flush to set GO bit, unblock updates 
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Bootstrapping Atomic State 


e atomic updates always incremental 
e assume that software state perfectly matches hardware 


° driver load and resume need to ensure matching state, use 
->reset hooks 


e need not actually reset, hardware state readout for fastboot 
also possible 
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Legacy Entry Points 


e helpers to implement them with atomic for all of them 


¢ allows drivers to keep old features that don't make sense to 
port to atomic around 
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Ongoing for 4.4 


e suspend/resume helpers 
e atomic fodev 
e active only plane update helpers 


e better support for runtime PM in general 
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Software 


Future Work 


e generic async commit 
e state readout for fastboot à la 1915 
e more helpers as use-cases crop up ... 


e generic validation tests in I-g-t perhaps 
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Software 


KMS Extensions 


e easy to do with properties 
e color manager, plane blending, ... 


¢ should put them into core drm state structures to avoid 
property proliferation 


e same rules as any other kernel ABI 
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Android Support? 


e just fences missing, but: 


e hardware composer wants per-buffer relase fence, even 
before the next flip is scheduled 


> trivial fencing deadlock 


e... and no one has an open-source atomic hwc 
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Documentation 


e conversion HOWTO for legacy drivers: 
http://blog.ffwil.ch/2014/11/atomic-modeset-support-for-kms-drivers.html 


e LWN design overview: https://lwn.net/Articles/653071/ 
https://Ilwn.net/Articles/653466/ 


e DRM DocBook: https://01.org/linuxgraphics/gfx-docs/drm/ 
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